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REMARKS 

The above amendment and these remarks are responsive to 
the Office action of Examiner Thong H. Vu f mailed 14 Jan 
2005. 

Claims 1, 4-5, 7-11, and 14-24 are in the case, none as 
yet allowed. 

Doubl e Pa ten t Ing 

Claims 1-24 have been rejected under the judicially 
created doctrine of double patenting over claims 1-14 of 
U.S. Patent 6,839,732 Bl (Vincent). 

Claims 1-24 have been provisionally rejected under the 
judicially created doctrine of double patenting over claims 
1-22 of copending Application No. 09/813,910. 

Applicants have amended claims 1, 4-5, 7-11, and 14- 
24, and with this amendment traverse these double patenting 
rej ections . 
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Vincent does not concern any kind of tunneling 
protocol, Vincent does not concern any VPN's, Vincent does 
not concern IP Sec-based VPN's, Vincent does not concern 
multiple VPN connections between endpoints, Vincent does not 
concern nested VPN" connections, and Vincent does not concern 
nested VPN connections with coincident endpoints. 

Since none of these concepts are contained in Vincent, 
Vincent does not identify , and does not solve any problems 
associated with these ideas. Generally stated; Vincent is 
quite irrelevant to current invention. Yes, they both 
involve TCP/IP , but of course, this is way too general and 
vague to be useful . 

The Examiner states, in trying to relate Vincent claim 
8 to the current invention claim 11, that "it is clearly 
that an operation to negotiate or define parameters included 
the encapsulate / decapsulate data is equivalent to the 
implement process for a queue using a pool of domain sockets 
to establish a TCP/IP inbound connection 

Applicants traverse. The current invention (all 
claims, as amended) uses the terms 'encapsulate 1 & 
'decapsulate' in the technical context of the IP Sec 
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protocol, and they do not mean 'an operation to negotiate or 
define parameters . . . connection 1 . 

With respect to copending Application No. 09/813,910, 
the copending application uses (exploits) the invention of 
the 'current invention 1 to further advantage by providing 
the benefits of VPN NAT. The copending application is 
about VPN NAT over nested VPN connections with coincident 
endpoints. One way of looking at it is that the new 
technical problems posed by current application caused VPN 
NAT to be 'broken 1 (essentially due to the particular 
problems around the coincident endpoints) . VPN NAT was too 
useful to allow this situation, so the copending application 
fixes it. 

A key difference between the copending application and 
the present application is found in claim 3 of the copending 
application, which states "... propagating a network 
address translation rule from said outer connection to said 
inner connection.". This gets to the heart of the 
technical problem solved by the copending application. 
Obviously the current application doesn't have this, since - 
the current application doesn't use VPN NAT. 
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Applicants request that the Examiner reconsider and 
withdraw the double patenting rejections. 

35 U.S.C+ 102 

Claims 1-24 have been, rejected under 35 U.S.C. 102(e) 
as anticipated by Giniger et al [Giniger 6,751,729 Bl] . 

Applicants have canceled claims 2,3,6,12,13, and have 
amended the other claims to clarify the distinctions with 
respect to the cited art, as those distinctions are 
described hereafter. 

Giniger does not anticipate the basic key concepts in 
the current invention, nor how the key concepts are 
combined, nor how they are used. Giniger does not solve 
the problems solved by the current invention, and in fact 
Giniger does not even address these problems. 

Each of -he claims has been amended (directly, or by 
amendment to base claims) to clarify these distinctions. 

The basic key concepts of the current invention are 
END920000092US1 23 of 34 S/N 09/813,911 
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those of a IP Sec-based VPN connection that has another such 
connection nested inside it. This has immediate 
implications for how protocol (Internet Protocol) traffic 
needs to be handled. 

In addition to the nesting, the current invention 
identifies and solves the special problems associated with 
nhese nested connections when the endpoints (on at least one 
end) of both of them reside on the same node. This makes 
them coincident. There are particular technical problems 
with this situation, and particular customer benefits to 
solving them. 

These basic concepts are simply not in Giniger, and not 
addressed by Giniger. Hence Giniger does not disclose how 
to solve them, and the claims all distinguish Giniger. 

Further detail and elaboration on these points in 
contained the responses below. 

Concerning item 6 "as per claim 11, Giniger discloses a 
method for nesting connections between a plurality nodes 
communication network, . . . '» The novel point is in the 2nd 
clause of claim 11, which recites the "outer connection". 

END920000092US1 24 of 34 S/N 09/813,911 
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Yes, both the current invention & Giniger use DHCP. Giniger 
does not use an outer connection. 

The point of the 3rd clause of claim 11 is that an 
inner (second) VPN connection is being set up. It is set up 
internally (tunneled, nested) v/ithin the 1st (outer) 
connection. Note that this is not two VPN connections 
between the same nodes; that is, not two parallel VPN 
connections. Yes, Ginigeir seems to establish an IP Sec- 
based VPN. But Giniger does not set up two connections and 
does not set up two connections with one nested inside the 
other. The 'tunneling communication service 3 50" in Fig 3 
of Giniger is merely the IP Sec tunneling mechanism. It is 
important that tunneling of IP traffic is basic to the IP 
Sec architecture (see for example, IETF RFC 2401) , In these 
terms, the current invention concerns a tunnel within a 
tunnel. Giniger does not do this. The Examiner's phrase 
1 internal data path 1 does not occur in Giniger page 10, 
lines 21-65. 

With respect to the 4th clause of claim 11, as amended, 
Giniger does not 'negotiate over outer connection parameters 
defining said secure nested inner connection 1 . The 
parameters referred to are the results of the IKE 
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negotiation, not a response from a DHCP server. Hence the 
cited section of Giniger (col 11 line 55 -col 12 line 2) is 
irrelevant . 

With respect to the 5th clause of claim 11, 'start said 
inner connection 1 refers to starting a nested IP Sec 
connection. Giniger does not have nested IP Sec 
connections, hence does not start nested IP Sec connections. 
The cited section of Giniger (page 12, lines 3-43) does not 
start a nested IP sec connection. In can be noted that 
starting a IP Sec connection is technically distinct from 
the IKE negotiation which precedes the start. (This 
negotiation, occurred in the previous clause.) 

With respect to clause 6 of claim 11, the 'linking 1 of 
the inner connection to the outer connection is crucial. 
This relationship is what allows the subsequent TCP/IP 
traffic (potentially of all types) to be correctly processed 
by the inner connection, then by the outer connection, at 
both ends of both connections . Even if Giniger does have 
'two pairs public/private keys' as the Examiner states, 
Giniger does not do this, because Giniger does not have an 
inner connection, hence does not link an inner connection to 
an outer connection. 
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Concerning item 7 of the Office Action, "as per claim 
8, Giniger discloses a method for operating a first one 
plurality of nodes in a communications network, ..." 

With respect to the 1st clause of claim 8, yes Giniger 
starts ('establish 1 ) tunnels. Giniger does not indicate 
that nested tunnels are used anywhere. Hence Giniger does 
not establish using an inner and an outer connection, and 
does not establish at a said first node a coincident 
endpoint for an outer and an inner tunnel , 

With respect to the 3rd clause of claim 8, Giniger does 
not selectively encapsulate said traffic to said outer 
connection. This is because Giniger does not contain the 
concept of an cuter connection. 

Concerning item 8 of the Office Action, "claims 21, 24 

contain the similar limitations set forth of method claims 

8. Therefore claims 21, 24 are rejected for similar 
rationale set forth in claim 8" . 

Applicants respond that Giniger does not contain nested 
tunnels, hence does not contain nested tunnels with 
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coincident endpoints {see fig 2 for an explanation of what 
coincident means for VPN connections, with corresponding 
text pp 7-10 of the current invention) . And importantly, 
Giniger does not link an inner connection to an outer 
connection. Yes, Giniger' s •root manufacturing certificate 
authority' has 'two pairs of public/private keys' (col 12, 
53-54). This has no bearing on the current invention for 
these reasons; the current invention does not require (but 
may use) security certificates of the sort Giniger refers 
to; even if an embodiment of the current invention used 
certificates, this use has no relevance on the structural 
relationship of two VPN connections of applicants' claims. 
Hence Giniger' s use of two pairs of keys is irrelevant. 

Concerning item 9 of the Office Action, "as per claim 
15, Giniger discloses a system for nesting connections 
between a plurality nodes a communication networks, 
comprising ..." 



Applicants traverse. The material cited by the 
Examiner, Giniger col 12, ling 44 -col 14, line 62, does not 
contain nested connections. Giniger does not contain nested 
connections anywhere. Hence Giniger also does not contain 
nested connections with coincident endpoints, 
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To elaborate, for example; the fact that the 
connections are nested with coincident endpoints places a 
unique and nontrivial technical problem on the node in which 
the coincident endpoints reside. There are various aspects 
to this technical problem which can be summarized as the 
problem of recognizing various classes of outbound and 
inbound IP traffic, and handling these various classes 
correctly. For outbound, for example, some traffic (between 
the respective nodes) must go inside the outer tunnel and 
not the inner tunnel, some traffic must go in the inner 
tunnel and the outer tunnel, and some traffic must go in 
neither. It is these sort of problems which are solved by 
the method and system of the invention as set forth in the 
amended claim 15. 

Concerning item 10 of the Office Action, "as per claims 
2-3, 9, 16-17 Giniger discloses said inner connection being 
a secure connection (or an IP Sec connection) ... (col 10, 
lines 21-65)": Applicants traverse. Giniger simply does 
not contain anything like an 'inner connection 1 . Not in 
the cited section, nor anywhere else. In the cited 
section, Giniger does refer to an 'internal data path 1 , as 
contrasted to an 'external interface module 1 . These are 
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shown in Giniger fig 3 as 312 & 320 respectively. Whatever 
they might mean. in the context of Giniger, it is very clear 
from Fig 3 that they cannot be alternate terms for what the 
current invention refers to as an inner and outer 
connection, for multiple reasons. First the 'external 
interface module 1 is not a VPN connection. Second, these 
two entities do not connect two network nodes. Third, they 
do not connect two nodes with coincident endpoints. All of 
these distinctions are set forth in all of applicants' 
claims as now amended. 



Concerning item 11 of the Office Action, "as per claims 
4, 7, 10, 14, 18 Giniger-Rao disclose a L2TP connection for 
tunneling packets across said communication network 
(Giniger, col 7, 322-52)": Though not specified in the 
statement of rejection, applicants assume the Rao is a 
reference to US 6,674,756 Bl . Yes both Giniger and Rao 
mention L2TP. But claims 4, 7, 10, 14 & 18 all build upon 
earlier claims, and hence make the point that the nested VPN 
connections of claims 1,2 & 3 (in the case of claim 4} , 5, 6 
(in the case of claim 7) , 8 & 9 (in the case of claim 10) , 
etc.; and these earlier claims concern ideas and concepts 
not in Giniger or Rao (or their combination), Hence 4, 7, 
10, 14 & 18 concern the novel nested connections with 
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coincident endpoints of the current invention, over L2TP 
(not merely the use of L2TP) . Hence the ideas in 4, 7, 10 , 
14 & 18 are not in Giniger or Rao (or combination) . 

Concerning item 12 of the Office Action, "as per claim 
6, Giniger discloses establishing a local coincident 
endpoint of said inner and outer connections at said gateway 
(Giniger, edge device, Fig 3)": Applicants traverse. 
Giniger fig 3 and all of its description, simply do not 
contain (and certainly do not disclose) a 'local coincident 
endpoint'. To see this, note that item 110 in Giniger fig 3 
corresponds to 16 in fig 2 of the current invention. 

Consider Giniger fig 8, items 815 r 825 and 835; yes it 
is true that these represent tunnels, but nowhere in Giniger 
is there any specifics beyond that. The tunnels are not 
nested but rather parallel. And in col 16 where Giniger 
mentions 'from tunnel 815 to a tunnel 825' he is referencing 
an end-to-end relationship between tunnels. Not a nesting, 
as all of the claims in the current case specifically state. 

Concerning item 13 of the Office Action, "as per claim 
12, Giniger discloses sending outbound traffic in said inner 
connection double nested in said outer connection (Giniger, 
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two pairs public / private keys, col 12, 44 - col 14, 62)": 
Applicants traverse. As mentioned earlier, the simple 
existence of two keys determines nothing about the 
relationship of corresponding tunnels.' In addition, the two 
keys only concern a single tunnel, since Giniger is using 
x.509v3 (col 12, line 58). Hence Giniger does not contain 
'sending outbound traffic in said inner connection double 
nested in said outer connection 1 . 

Concerning item 14 of the Office Action, "as per claim 
13, Giniger discloses operating said ISP node to decapsulate 
said outer connection; and operating said client node to 
decapsulate said inner connection as inherent features of 
two pairs of public/private keys": Applicants traverse. 
Giniger does not decapsulate said outer connection followed 
by decapsulate an inner connection. In fact Giniger does 
not even decapsulate an outer connection, but rather merely 
decapsulated traffic from a connection. The qualification 
of 'outer' (and 'inner') is completely unnecessary in 
Giniger because Giniger does not use, or contain, or 
disclose the concepts associated with nested connections. 

Concerning item 15 of the Office Action, "claims 1, 5, 
19, 20, 22, 23 contain the similar limitations set forth of 
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apparatus claim 15. Therefore, claims 1, 5, 19, 20, 22, 2 3 
are rejected for the similar rationale set forth in claim 
15": These objections are addressed above under response to 
item 9 of the Office Action, concerning claim 15. The above 
response applies to 1, 5, 19, 2 0, 22 and 23. 



SUMMARY AND CONCLUSION 



Applicants urge that the above amendments be entered 
and the case passed to issue with claims l, 4-5, 7-11, and 
14-24, 

The Application is believed to be in condition for 
allowance and such action by the Examiner is urged. Should 
differences remain, however, which do not place one/more of 
the remaining claims in condition for allowance, the 
Examiner is requested to phone the undersigned at the number 
provided below for the purpose of providing constructive 
assistance and suggestions in accordance with M.P.E.P. 
Sections 707. 02 (j) and 707.03 in order that allowable claims 
can be presented, thereby placing the Application in 
condition for allowance without further proceedings being 
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necessary . 



Sincerely, 

E. B. Boden, et al 

By 




Shell^ Beckstrand 
Reg. No. 24 , 88 6 



Date: 14 Apr 2005 

Shelley M Beckstrand, P.C. 
Patent Attorney 
61 Glenmont Road 
Woodlawn, VA 24381 

Phone: (276) 238-1972 
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